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(57) Abstract 

The present invention provides a graphical user interface (GUI) (404) and network based telephony system (206) and method for 
establishing an audio conference. In a network environment where a plurality of computers connected to allow audio/text conferences 
and peer-to-peer text messaging. Once a conference is created, each participant may add a new participant to the conference at any time 
during the conference call by sending a call request to the computer of the new participant. All participants in an audio conference may 
freely speak at any time they want without losing information or audio data from other participants. Each of the participants in an audio 
conference is in audio communication with other participants. This functionality is achieved by combining a buffer control mechanism and 
an audio conference facility (710). The invention also allows peer-to-peer text/audio messaging between the computers in the network and 
overcomes firewall incompatibility problems. 
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APPARATUS AND METHOD FOR ESTABLISHING AN AUDIO 
CONFERENCE IN A NETWORKED ENVIRONMENT 



This application claims priority to United States Provisional Patent Application 
Serial No. 60/127,364, filed April 1, 1999, entitled "Internet Telephony System and 
Method," by James E. G. Morris and Edward A. Lemer, and to United States 
Provisional Patent Application Serial No. 60/137,888, filed June 7, 1999, entitled 
5 "Interface for a Voice-Over-Network Application," by Edward A. Lemer and Arthur 
W. Min. 



BRIEF DESCRIPTION OF THE INVENTION 

The present invention relates generally to audio communication. More 
10 specifically, the present invention relates to a network application for placing and 
receiving audio calls and conducting multi-party audio conferences in a networked 
environment. 



CROSS-REFERENCE TO RELATED DOCUMENTS 

1 5 The present invention is related to the subject matter disclosed in U.S. Patent 

No. 5,764,900 ("System and Method for Communicating Digitally-Encoded Acoustic 
Information Across a Network between Computers"), U.S. Provisional Patent 
Application Serial No. 60/127,364 ("Internet Telephony System and Method"), U.S. 
Provisional Patent Application Serial No. 60/137,888 ("Interface for a Voice-Over- 

20 Network Application"), and U.S. Patent Application Serial No. 

("Apparatus and Method for Creating Audio Forums") filed July 22, 1999. Each of 
these documents is assigned to the assignee of the present application and incorporated 
herein by reference. 
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BACKGROUND OF THE INVENTION 

Conventional telephone and conference calls are made using Public Switched 
Telephone Networks (PSTNs) and/or commercial wireless networks. More recently, 
telecommunications services have begun to view the Internet as an alternative, less 
5 costly method for transmitting audio calls. The art of developing systems that enable 
two or more persons to connect through the Internet and conduct real-time 
conversations is often referred to as "Internet telephony." 

Prior an Internet telephony systems suffer from a number of disadvantages 
when compared to PSTN-based telephony systems. First, many prior an systems are 

10 difficult to configure and use. particularly for users with limited technical experience. 
Second, prior an telephony systems are frequently incompatible with network 
firewalls that are used to restrict access to and from network resources. Third, many 
Internet telephony systems do not offer multi-party conferencing capability. 

Further, prior art Internet telephony technology makes it difficult to implement 

1 5 a computer graphical user interface ("GUI") for multi-party conferencing. For 
example. FIG. 1 illustrates a prior an web browser-based voice conferencing 
environment. The user ace885 is connected to a specific chat room (site) in order to 
conduct a voice conference with users nedl 1111 and tinitina99. The current "chatter" 
is ace885. as indicated by the "ON-AIR" sign next to ace 885. When ace885 is "ON- 

20 AIR," other conference participants can not speak. When ace885 releases the 

communication channel, either nedl 1 1 1 1 or tinitina99 may speak, depending upon 
which conference participant secures the channel first by pressing the "READY" 
button. 

In this connection, conference participants may secure the communication 
25 channel and speak by toggling their "ON-AIR" button to "READY." The conference 
participant who presses the "READY" button first is granted access to the channel and 
is allowed to speak. Thus, a prior art computer GUI for multi-party conferencing 
represents a somewhat limited and inconvenient option to its user, which creates 
undesirable race conditions. 
30 Moreover, it is possible to lose information in prior art Internet telephony 

systems. As an illustration, more than two people may race to press the "READY" 
button in an attempt to secure the communication channel at the same time. 
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Unfortunately, anything which might be spoken by the person who lost the race to 
secure the communication channel will not be heard by other conference participants 
and is consequently lost. 

Also, in prior art Internet telephony systems, the conversation in a conference 
5 call is broadcast to all participants unless blocking is done using option menus. 
Unfortunately, prior art blocking requires a user to execute blocking every time the 
user joins a conference. 

In view of the foregoing, it would be highly desirable to provide an improved 
Internet telephony system. In particular, it would be highly desirable to provide an 
10 improved GUI for conducting multi-party audio conferences. 



SUMMARY OF THE INVENTION 

The present invention provides a GUI and network-based telephony system and 
method for establishing an audio and/or text conference. In a network environment 

15 where a plurality of computers are connected, the invention generates a call request in 
response to the call request of a first user who is connected to one of the networked 
computers. The computer to which the first user is connected transmits the call 
request to a second computer on the network, notifying the second computer of the call 
request and the identity of the first user. When a second user connected to the second 

20 computer accepts the call request from the first user, the present invention establishes a 
connection between the first and second computers. Once a connection is established 
between the first and second users, the users may conduct an audio and/or text 
conference and/or engage in peer-to-peer messaging. 

The GUI of the invention displays the participants in a conference and provides 

25 a contacts list. On the GUI, each participant in the conference can see a contacts list 
and a user list, add/find a user, and initiate a text conference by engaging a button on 
the GUI. A participant in an audio or text conference may add a new participant to the 
audio or text conference at any time during the conference by sending a call request to 
the computer of the new participant. In an embodiment of this invention, an audio 

30 conference participant need only select a name on the contacts list with a single mouse 
click to initiate a call request to the computer of the new participant. If the new 
participant accepts the call request, all audio or text communication originating from 
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the conference participants is directed to the new participant depending on the type of 
conference being created. Thereafter, all audio or text communication originating 
from the new participant is broadcast to other conference participants. 

The invention is highly advantageous because all participants in an audio 
5 conference may freely speak at any time they want without losing information or audio 
data from other participants. Each of the participants in an audio conference is in 
audio communication with other participants. This functionality is achieved by 
combining a buffer control mechanism and an audio conference facility. The 
computers in the network utilize a buffer and a buffer control mechanism in order to 

10 eliminate overflow conditions and reduce audio data loss. 

In addition, the invention allows direct peer-to-peer messaging between the 
computers in the network. If a client computer with which a peer-to-peer messaging is 
desired is behind a firewall, the present invention enables that client computer to route 
messages through an audio server, thereby overcoming firewall incompatibility 

1 5 problems. 

BRIEF DESCRIPTION OF THE DRAWINGS 

For a better understanding of the invention, reference should be made to the 
following detailed description taken in conjunction with the accompanying drawings, 
20 in which: 

Figure 1 illustrates a typical prior art audio conferencing system based on a 
web browser. 

Figure 2 illustrates the general architecture of the multi-party conference 
system 200 according to one embodiment of the present invention. 
25 Figure 3 illustrates components of an exemplary client computer 202 that may 

be used in accordance with one embodiment of the invention. 

Figure 4 illustrates a memory 304 of a client computer utilized in accordance 
with one embodiment of the invention. 

Figure 5(A) illustrates the structure of an audio data packet used in accordance 
30 with one embodiment of the invention. 
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Figure 5(B) illustrates an operation of the overflow buffer 412. the sound 
buffer 410. and the sound mixer 408 in greater detail in accordance with one 
embodiment of the invention. 

Figure 6 illustrates functional components of a webtalk engine 406 utilized in 
5 accordance with one embodiment of the invention. 

Figure 7 illustrates a client computer and an audio server connected through a 
network in accordance with one embodiment of the invention. 

Figure 8 illustrates a GUI of an audio communication application provided in 
accordance with one embodiment of the present invention. 
10 Figure 9 illustrates processing steps for an audio communication application 

that may be executed in accordance with one embodiment of the invention. 

Figure 10 illustrates an example of a "Find User" window provided in 
accordance with one embodiment of the invention. 

Figure 1 1 illustrates an example of a user option window 1 101 provided in 
1 5 accordance with one embodiment of the invention. 

Figure 12 illustrates processing steps for creating a block list for a user in 
accordance with one embodiment of the invention. 

Figure 13 illustrates a login window 1301 provided in accordance with one 
embodiment of the invention. 
20 Figure 14 illustrates processing steps for connecting to a server for a 

conference in accordance with one embodiment of the invention. 

Figure 1 5 illustrates an example of a broadcast window 1501 opened by user 
CNF Room for text conferencing. 

Figure 16 illustrates a text messaging window 1601 activated in accordance 
25 with one embodiment of the invention. 

Figure 17 illustrates processing steps performed by a server for transmission of 
audio data to client computers in accordance with one embodiment of the invention. 

Figure 1 8 illustrates processing steps of a client computer for receiving audio 
data in accordance with one embodiment of the invention. 
30 Figure 1 9 illustrates an alternate embodiment of processing steps for receiving 

audio data for a client computer. 
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Figure 20 illustrates an alternate embodiment for processing steps for 
controlling audio data transmission. 

Figure 21 illustrates processing steps for conducting multiple calls and 
conferences for a client computer in accordance with one embodiment of the 
5 invention. 

Figure 22 illustrates processing steps of a server for establishing a peer-to-peer 
messaging session in accordance with one embodiment of the invention. 

Like reference numerals refer to corresponding parts throughout the drawings. 



1 0 DETAILED DESCRIPTION OF THE INVENTION 

FIG. 2. illustrates the general architecture of a multi-party conference system 
200 according to one embodiment of the present invention. In the system 200, 
computer devices are coupled for intercommunication via a public or private network 
such as the Internet. The computer devices include a plurality of client computers that 

1 5 are connected to a network 206 through any one of a number of interfaces. For 
example, a first client computer 202 is connected to the network 206 via either a 
wireless or dial-up modem connection to a network service provider 203 such as a 
commercial Internet Service Provider (ISP), a second client computer 204 connects to 
the network 206 via a T-l line interface, and other client computers 210-220 connect 

20 to the network 206 via first and second Local Area Networks (LANs) 230 and 232. 

The LANs may be protected with conventional firewalls 234 and 236 to inspect 
incoming packets and reject those originating from unauthorized or suspicious 
addresses and/or to limit outgoing packets. Other client computers may be connected 
to the network 206 via alternative interfaces. It will be appreciated by one skilled in 

25 the art that while a total of eight client computers are shown in FIG. 2, the present 
invention may be practiced using any number of client computers. There is at least 
one user associated with each of the client computers. The network 206 represents any 
suitable electronic media through which a plurality of computers may be connected, 
such as the Internet. 

30 The system 200 shown in FIG. 2 also comprises audio servers 240-1 to 240-N 

coupled to the network 206, preferably via a high-bandwidth interface. The exact 
number of servers used in FIG. 2 is not important and any number of servers may be 
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used in accordance with the technology of the present invention. Each of the audio 
servers 240 comprises a computer having at least one processor, an interface to the 
network 206. and a memory (primary and/or secondary) for storing program 
instructions and other data. The audio servers 240 are collectively operative to enable 
5 each one of the client computers to conduct audio communications with any other 
client computers. Each audio server is specifically operative to initiate 
calls/conference connections responsive to a connection request received from an 
associated client computer, to determine the appropriate call architecture and protocol 
based on predetermined parameters, and to route audio data to one or more selected 

1 0 recipient client computers. 

A database system 250, typically comprising one or more server computers, 
may also be coupled to the network 206 and may be configured to perform certain 
operations such as authentication of users desiring to utilize the services of the 
telephony system. In alternate embodiments of the invention, it is also possible that 

1 5 client, server, and database functions may be combined in a single computer. 

Alternatively,, any two of the client, server, and database functions may be combined 
and implemented on a single computer. 

FIG. 3. illustrates components of an exemplary client computer 202. It is noted 
that FIG. 3 is jntended to serve simply as a conceptual representation of the client 

20 computer, rather than illustrate an actual computer architecture. For example, those 
skilled in the art will recognize that multiple buses (rather than a single bus 3 14. as 
depicted) are typically employed to enable communication between the several 
components. 

The client computer 202 includes a CPU (Central Processing Unit) 302 for 
25 executing instructions and controlling communication between and among the various 
components of the computer 202, and a memory 304 for storing data such as program 
instructions or text files. One or more non-volatile storage devices 306, such as floppy 
drives, hard disks and the like, may be operable to store and retrieve applications, data 
and text files, and other information. The client computer 202 is also provided with a 
30 loudspeaker 3 10 for converting to sound electrical signals representative of the audio 
transmissions of users of other client computers. The client computer 202 may 
additionally be provided with either a microphone 308 for generating electrical signals 
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representative of the speech of the associated user or some other audio signal 313. The 
microphone 308. loudspeaker 3 1 0. and audio signal 313 may be connected to the client 
computer through a sound card 312, which performs the requisite analog-to-digital and 
digital to analog signal conversion. Alternatively, the CPU 302 can perform these 
5 functions. Also coupled to the client computer 202 are a display device 3 16. a 

network interface 3 1 8 (such as an Ethernet card or modem) to enable connection of the 
computer 202 to the network, either directly or indirectly, and additional input/output 
devices 320. such as a keyboard, mouse, or printer. 

FIG. 4 illustrates a typical structure of memory 304 of the client computer 202. 

10 The memory 304 comprises an operating system 402, a user interface module 404, a 
webtalk engine 406. a sound mixer 408. a sound buffer 410, and. optionally, an 
overflow buffer 412. The operating system 402 is operative to allocate memory and 
perform other low-level functions of the client computer 202. The user interface 
module 404 may comprise, for example, a conventional browser or audio 

1 5 communication application, and is preferably provided with a GUI that enables a user 
to interact with the client computer 202 by entering text, selecting icons, or performing 
similar operations. The browser in the user interface module 404 can be any of the 
commercially available browsers such as Netscape Communicator. Internet Explorer, 
or Opera. The audio communication application may run in a Microsoft Windows 

20 environment, although other platforms are within the scope of the invention. The 
operation of the audio communication application is described in U.S. Patent No. 
5.764.900 and U.S. Provisional Patent Application No. 60/127.364. 

The webtalk engine 406 enables a user to send and receive real-time audio 
communications to and from one or more remote users associated with other client 

25 computers. The webtalk engine 406 is preferably implemented as an ActiveX control 
or other form of linked library. The sound mixer 408 is used for mixing acoustic 
signals. In one embodiment of the invention, the sound mixer 408 is implemented by 
using a Microsoft operating system call. In an alternate embodiment of the invention, 
the sound mixer 408 is implemented directly on an audio card. It will be appreciated 

30 that numerous other implementations are possible for the sound mixer 408. 

The sound buffer 410, which may comprise one 410-1 or more 410-N 
individual sound buffers, is used to store acoustic signals received from other client 
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computers. The overflow buffer 412. which may comprise one 412-1 or more 412-N 
individual overflow buffers, may be used to store overflow acoustic signals when the 
sound buffer 410 is unable to accept additional audio data. 

In a preferred embodiment of the invention, the sound buffers of a client 
5 computer continue to convert their contents to sound and play it to the user regardless 
of whether the user is speaking. In the preferred embodiment, the audio data stored in 
four buffers are mixed together, convened to sound and presented to the user so that 
the user can hear other users speaking at the same time that the user is speaking. This 
embodiment eliminates the need to pause conversion of the buffer contents into sound 

1 0 when the user is speaking. 

In an alternate embodiment of the invention, the conversion of the contents of 
the sound buffers to sound is paused by the client computer when the user of the client 
computer starts speaking. When the user stops talking, the sound buffers resume 
converting their content to sound. Optionally, pauses in human speech may be 

1 5 compressed. The effect of the buffer pause is that the user does not miss what other 
people are saying while the user was talking. The processing of current audio data is 
completed after the client computer finishes conversion of the buffer contents to 
sound. 

FIG. 5(A) illustrates the structure of a typical audio data packet used in 
20 accordance with one embodiment of the invention. The packet 500 shown in FIG. 
5(A) comprises a packet header 502 and payload 504. The packet header 502 has 
network protocol information such as the TCP (Transmission Control Protocol) or 
UDP (User Datagram Protocol), and IP (Internet Protocol) packet header information. 
In a preferred embodiment, the payload 504 is formatted to specify a type of packet, a 
25 start/middle/end-of-data indicator, the identity of the user who originated the packet, 
the packet data size, the packet sequence number, and one or more flag bytes. The 
information contained in the packet payload 504 is used by a recipient client computer 
to determine the size, origin, and sequence number of the incoming packet. In 
alternate embodiments of the invention, the identity of the user who originated the 
30 packet is not included in the payload 504. and the recipient computer relies on the 
information contained in the header 502 to determine the source of the packet. 
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FIG. 5(B) illustrates an operation of the overflow buffer 412. the sound buffer 
410. and the sound mixer 408 in greater detail in accordance with one embodiment of 
the invention. A packet control module 508 of a client computer (for example 202) is 
coupled to the network interface 3 1 8 such as an Ethernet card or modem, to the sound 
5 buffer 410. and to the overflow buffer 412. In the embodiment shown in FIG. 5(B). 
the sound buffer 410 is implemented by sound buffers 410-1 through 410-N. 

The packet control module 508 receives incoming audio packets and 
determines where they should go. For example, the packet control module 508 routes 
an incoming packet from other client computer to the corresponding sound buffer, say 
10 410-1. when the buffer 410-1 is available. If the buffer 410-1 is full and/or otherwise 
unable to receive a new packet, the packet control module 508 sends the received 
packet to the overflow buffer 412 for subsequent processing. 

The sound buffers A through N 410 provide sound data received from the 
packet control module 508 to the sound mixer 408. which is coupled to an output 
1 5 device such as a speaker for conversion to audible sound. In one embodiment of the 
invention, there are a maximum of four audio streams played simultaneously in a 
client computer. For each audio stream, there is a corresponding sound buffer in the 
client computer. Each audio stream may be thought of as representing a "phone line" 
between the client computer and a different user that is participating in the audio 
20 conference call with a user associated with the client computer. Although four audio 
streams are played simultaneously in one embodiment of the invention, any number of 
audio streams may be played simultaneously in accordance with the invention. 
However, playing more than four streams simultaneously may make the sound 
unintelligible and/or may exceed the data transmission bandwidth available to client 
25 computers, especially those connecting to the network at slower speeds. 

The packet control module 508 shown in FIG. 5(B) may be implemented as a 
software routine or with the use of hardware circuits. There are various methods that 
can be used by the packet control module 508 to store and retrieve audio data in FIG. 
5(B). In one embodiment of the invention, a FIFO (First In First Out) technique is 
30 used to determine the order in which incoming audio data is stored in and retrieved out 
of an overflow buffer (for example 4 1 2) of a client computer (for example 202). In 
alternate embodiments of the invention, however, any other suitable queuing system 

10 
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may be used in conjunction with the present invention. For example, a priority-based 
queuing system. LIFO (Last In First Out), and other suitable queuing systems, alone or 
in combination, may be used in conjunction with the invention. 

FIG. 6 illustrates functional components of the webtalk engine 406. The 
5 webtalk engine 406 comprises executable instructions forming a communication 
module 602, an audio module 604, and an interface module 606. The communication 
module 602 is configured to control communication between the client computer 202 
and an associated audio server 240 or other computers. 

The audio module 604 controls the packet control module 508. the sound 

10 buffer 410, and the sound mixer 408 to provide buffering, mixing, and related 
processing in connection with incoming and outgoing audio data packets. One 
example of the audio module 604 is described in U.S. Pat. No. 5,764,900 entitled 
"System and Method for Communicating Digitally-Encoded Acoustic Information 
Across a Netw ork Between Computers." which is incorporated herein by reference. 

15 Those skilled in the art will recognize that the functions provided by the audio module 
604 may be achieved in any number of alternative implementations. Finally, the 
interface module 606 is configured to control the flow of information between the user 
interface module 404 and the webtalk engine 406. 

FIG. 7 illustrates a client computer (for example 202) and an audio server 240 

20 connected through the network 206. In FIG. 7, the client computer 202 comprises the 
components shown in FIG. 3. The input/output devices 320 include a monitor 316 and 
a keyboard 71 8. In addition, the memory 304 of the client computer 202 comprises a 
contacts database 720 and a user profile database 722. Among other things, the 
contacts database 720 can be used to store the names of persons known to the user, 

25 persons with whom the user had a conference call previously, or other individuals 
having access to the telephony system. The user profile database 722 can be used to 
store information related to the user such as user name, password, and ID. The client 
computer 202 is coupled to the audio server 240 through the network 206. 

The server 240 comprises a network interface 712, a CPU 714. and a server 

30 memory 700. A bus 716 interconnects the network interface 712, the CPU 714, and 
the server memory 700. The server memory 700 comprises a registered user database 
702 for storing information about each user who is registered to log into the system 

11 
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200. a webtalk server application 704 for controlling calls and multi-party conferences 
between or among client computers, and a region for storing user data 706. In 
addition, the server memory 700 may contain a buffer 708 and/or a conference 
participants database 710. In an alternate embodiment of the invention, the registered 
5 user database is maintained on a separate server to minimize the load on any particular 
computer. 

The user data 706 will typically include, for each user connected to the audio 
server, the following information: a socket number associated with the connection, a 
nickname and/or user ID. a watch list (a list of users with whom the user frequently 

10 communicates), user status information (e.g.. whether the user is currently engaged in 
a call or conference, or otherwise unavailable to receive a call), and configuration 
parameters characterizing the nature of the connection of the user to the audio server 
(e.g., whether the client computer associated with the user is located behind a firewall). 
The conference participant database 710 can be used to store the names or other 

1 5 identifiers of the participants of a conference call. The content of the conference 
participant database 710 changes as participants are added to or removed from a 
conference. 

The buffer 708 of the audio server memory 700 is used to store overflow 
packets and prevent audio data loss in cooperation with the overflow buffer 412 of the 

20 client computer. It will be appreciated by one skilled in the art that the exact number 
and size of the buffer 708 of an audio server and the overflow buffer 412 of a client 
computer are not important to the invention as long as they provide adequate flow 
control to prevent audio data loss. For example, in one embodiment of the invention, 
the audio server may contain a large overflow buffer and the client computer a smaller 

25 overflow buffer while in an alternate embodiment of the invention, the audio server 
may contain a small overflow buffer and the client computer a larger overflow buffer. 

The general architecture and processing associated with the invention has now 
been disclosed. Attention presently turns to a more detailed discussion of the system 
of the invention and the advantages associated with the disclosed technology. FIG. 8 

30 illustrates a GUI of an audio communication application provided in accordance with 
one embodiment of the present invention. In particular, the figure shows a GUI 801 
which includes a menu bar 802. a status symbol 805, a Do-Not-Disturb (DND) button 
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807. a Forum button 809. a contacts list 81 L a user status indicator 813. a user list 
815. a Time In Call indicator 8 1 7. a Mute button 819. a Text Chat button 821. a 
Hold/Pick Up button 823, a Hang Up button 825. a Add/Find users button 827. a 
Shadowtalk Launch button 829. and a caller status indicator 83 1 . 
5 Typically, a user on a client computer, such as one of the client computers 

shown in FIG. 2. activates the GUI of FIG. 8 by engaging an icon representing the 
audio communication application of the present invention. For example, the GUI 
shown in FIG. 8 is activated by engaging a "FireTalk" audio communication 
application icon on a client computer that includes the present invention. 

10 The contacts list 81 1 is established by adding desired users to the list with the 

add button 827 or other suitable means. When the user status indicator 813 indicates 
"Ready." a user may start a group audio or text conference. When the user initiates a 
conference, the user status indicator 813 changes to "Active." A group audio 
conference is initiated by clicking on a user on the contacts list 81 1 who has a 

15 telephone symbol next to the user, which indicates that the user is on-line and 

available to receive a phone call. For example, BAT0 and Elise in the contacts list 811 
are on-line and a group audio conference may be conducted among BAT0, Elise, and 
the current user. 

When a user initiates a conference, participants in the conference are displayed 
20 in the user list 815. For example, in FIG. 8. a conference is in progress between the 
current user (CNF_Room) and Dave. 

In accordance with the embodiment shown in FIG. 8. a user may receive a 
separate call while in a conference call by selecting the "Hold/Pick Up" button 823 on 
the main screen display of the audio communication application. Selecting the 
25 "Hold/Pick Up" button 823 places the user in communication with the incoming call 
and puts the original call/conference on hold. When the original call/conference is 
placed on hold, the caller status indicator 83 1 changes to "On Hold." A user may be in 
communication with multiple conference calls. While the user is communicating in a 
conference, other conferences may be placed on hold by selecting "Hold/Pick Up" 
30 button 823. 

FIG. 9 illustrates processing steps for an audio communication application that 
may be executed in accordance with one embodiment of the invention. In the first 

13 
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processing step shown in FIG. 9. the user interface module 404 of a client computer 
(for example 202) detects the user's call request to another user when the user uses a 
GUI (for example 801 of FIG. 8) of the present invention and clicks on an icon (i.e., 
aligns a pointer with the person's icon and engages a mouse button) or on the text 
5 corresponding to the selected call recipient in the contacts list 811 (step 901). The 
interface module (for example 606) of the client computer then relays the information 
to the communication module (for example 602). which in turn relays the requested 
call to the server (for example 240) (step 903). The GUI of the user interface module 
404 of the client computer 202 displays the name of the selected call recipient to the 

1 0 user window (for example the user list 8 1 5 in FIG. 8) of the client computer 202 (step 
905). Thus, the list of conference participants is displayed in the user list 815. 

The server reads the relayed information and identifies the call request to 
determine the source of the call request and the identity of the requesting party (step 
907). The server notifies the selected call recipient of the call request and the identity 

1 5 of the requesting party (step 913). If the intended call recipient refuses to take the call 
(step 915), the server notifies the requesting party of the result (step 917). If the 
intended recipient accepts the call, the server registers the call recipient's name in its 
memory as a participant of a conference call and updates its memory, for example the 
conference participant database 710 of FIG. 7 (step 919). The server then establishes 

20 communication between the user who made the initial call request and the call 

recipient such that all audio data being sent from the user is forwarded to the client 
computer 202 corresponding to the call recipient (step 921). and all audio data from 
the call recipient is forwarded to the user who made the initial call request (step 923). 
If a multi-party conference was already in progress in which the user is a 

25 participant, the server establishes communication in steps 921 and 923 such that each 
of the conference participants including the newly selected user are in audio 
communication with all other participants in the conference. Thus, while a conference 
is in progress, the server broadcasts the conference to all conference participants and 
each of the conference participants is in audio communication with each other. 

30 At this point, unique attributes of the embodiment represented by FIGS. 8-9 

will be apparent to those skilled in the art. The invention is highly advantageous 
because it provides a visual window where a user may see a list of contacts, select a 

14 
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name therein, find a new contact, or initiate a conference in which all participants are 
in audio communication with each other. This functionality is achieved by combining 
a buffer control mechanism with a novel multi-party conferencing GUI. as will be 
described in greater detail below. 
5 When the user wishes to find another user, the user can initiate a search by 

pressing the find button 827. which activates a "Find User" window. FIG. 10 
illustrates an example of the "Find User" window. The "FindUser" window 1001 
shown in FIG. 10 comprises "FireTalk ID" space 1003, "Nickname" space 1005. 
"Email" space 1007. "First Name" space 1009, "Last Name" space 101 1, "Matching" 

10 list 1013, a "Find" button 1015. a "Add User" button 1017, a "Call" button 1019, and a 
"Cancel" button 1021. 

FIG. 1 1 illustrates an example of a user option window 1 101 that is activated 
when the user CNFRoom clicks the right mouse button after selecting the name 
BAT0 from the contacts list 811. If CNFJloom wants to block the user BAT0 from 

15 future conference calls. CNFJloom selects the "Block & Remove Contact" button 
from the user option window 1101. Each participant in a conference call may form a 
block list to exclude certain users from audio communication. In the example shown 
in Figure 8, CNFJloom may block other users from a group conference by setting 
appropriate parameters by. for example, engaging the right mouse button after 

20 selecting a user name from the contacts list 8 1 1 . 

FIG. 12 illustrates processing steps for creating a block list for a user. In FIG. 
12. when a user selects a block menu from the user option window 1101 on a client 
computer (for example 202) and engages a mouse button to block another user, the 
GUI of the user interface module 404 detects the user's block request (step 1201). The 

25 interface module 606 of the webtalk engine 406 relays the block request received from 
the user interface module 404 to the communication module 602 (step 1203), which 
then transmits the information to a server (for example 240) (step 1205). The server, 
upon receiving the block request, identifies the user who is requesting the block and 
the user who is to be blocked (step 1207). The server then updates the user data 706 

30 on its memory 700 to register the blocked user (step 1 209). and stops all 

communication between the blocked user and the block-requesting user (step 1211). 
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Unlike prior art conference systems, the blocking mechanism of the present 
invention stores the blocking parameters set by the user in the client memory 304 in. 
for example, the user profile database 722. The blocking parameters may also be 
stored in the registered user database 702 in a server. In an alternate embodiment of 
5 the invention, the registered user database 702 containing the users* blocking 

parameters is stored in a separate off-line database so that even if the user logs on to 
the system from a different client computer, the user would not need to set the 
blocking parameters again because the blocking parameters may be retrieved from the 
off-line database for the user. 

10 FIG. 13 illustrates a login window 1301 where a user is required to enter the 

user's ID and password before using the audio communication application of the 
present invention. A login window may be activated by selecting the "Login" button 
under "File" menu in menu bar 802. In FIG. 13. the login window 1301 comprises a 
"Create New Account" button 1302. a "FireTalk ID" space 1303. a password space 

15 1305. a "Look Up FireTalk ID" button 1307, a "Forgot Password" button 1309. a 
"Login" button 131 1, a "Cancel" button 1313, and a "Help" button 1315. A user 
selects the "Create New Account" button 1302 when the user wants to create a new 
audio communication application account. A user with an existing "FireTalk" account 
may enter the user's name and password in the "FireTalk ID" space 1303 and the 

20 password space 1 305, respectively. The "Look Up FireTalk ID" button 1 307 and the 
"Forgot Password" button 1309 are used to allow a user to find a user ID and password 
in case the user forgets them. 

FIG. 14 illustrates processing steps for connecting to a server for a conference 
over the network. In FIG. 14. when a user selects a "Login" button under the "File" 

25 menu in the menu bar 803 on a client computer (for example 202). the GUI of the user 
interface module 404 detects the user's login request (step 1401). The interface 
module 606 relays the login request to the communication module 602 (step 1403), 
which then transmits the information to a server (for example 240) (step 1405). The 
server, upon receiving the login request, identifies the user who is requesting the login 

30 (1407), and verifies the identity of the login requester against a list of identifiers 
corresponding to authorized or registered users of the conference system 200 (step 
1409). 
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The authentication step 1409 is an optional step. Further, in alternate 
embodiments of the invention, the authentication step 1409 may use more secure 
authentication procedures including handshaking and/or encryption technology. 
If the login requester is not an authorized user, then the server sends an 
5 appropriate message to the client computer and disconnects the unauthorized user (step 
1411). If the login requester is an authorized user, the server updates the user data 706 
on its memory 700 to register the login user (step 1413). and continues communication 
with the client computer (step 1415). 

FIG. 15 illustrates an example of a broadcast window 1501 opened by 

10 CNFRoom. CNFRoom initiates the broadcast window by selecting 'Text Chat" 
button 821 on GUI 801, which opens the broadcast window 1501. When CNF Room 
selects the "Text Chat" button 82 L the client computer sends the selection to the 
server (for example 240). which then establishes a connection for text conferencing 
between CNF_Roorrf s computer and the computer of the user with whom CNF Room 

1 5 intends to conduct a text conference. 

In the embodiment shown in FIG. 15, an audio conference and a text 
conference are conducted simultaneously between conference participants, as 
illustrated by user list 8 1 5 (FIG. 8) and the broadcast window 1501. When a text 
conference is conducted between participants of a conference call using the broadcast 

20 window, the text conference is visible to all the participants in the conference call, and 
all the participants see the same content in their broadcast window if they have a 
broadcast window open. In the embodiment shown in FIG. 1 5. a broadcast window 
for a text conference may be toggled between being displayed and not displayed by 
pressing the "Text Chat" button 821 (FIG. 8). 

25 Although the broadcast window 1501 is used for text conferencing in the 

embodiment shown in FIG. 15, the broadcast window 1501 may also be used for other 
applications such as for creating, viewing, and editing documents, files, graphical 
images, video clips, and other electronic media. 

In addition to conducting an audio conference and viewing a broadcast 

30 window, the invention enables conference participants to send peer-to-peer messages 
in accordance with the technology of the present invention. Participants in an audio or 
text conference and participants in peer-to-peer messaging need not be the same. For 
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example, while a conference is in progress between CNF_Room and Dave, a text 
message may be sent to CNF_Room by ? for example. "Anthony" independent of the 
conference call between CNFRoom and Dave. 

FIG. 16 illustrates a text messaging window 1601 activated in accordance with 
5 one embodiment of the invention. The text messaging window comprises a "FireTalk 
ID" space 1603 for entering FireTalk ID. a "Message" window 1605 for entering a text 
message, a "Cancel" button 1607 for canceling the messaging, and a "Send" button 
1609 for sending the text message. In one embodiment of the invention, a user may 
activate a text messaging window by selecting a user and opening a user option 

10 window 801 shown in FIG. 8 by clicking on the right mouse button. The user then 
selects "Send Instant Message" button from the user option window 801 to open a text 
messaging window. 

FIG. 17 illustrates processing steps performed by a server for transmission of 
audio data to client computers in accordance with one embodiment of the invention. 

1 5 In the first processing step of FIG. 1 7. the server (for example. 240) checks its buffer 
to see if there is some audio data that can be retrieved and transmitted (step 1 70 1 ). If 
there is audio data to be sent in the buffer, the server checks to see if its transmission 
would cause a saturation condition at the destination client computer(s). which may 
result in an overflow condition and loss of audio data (step 1703). In one embodiment 

20 of the invention, the server monitors the volume of audio data sent to each client 
computer. If the volume of audio data transmission to a certain client computer 
reaches a predetermined value during a predetermined period of time, the server 
determines that further transmission to that particular client computer would saturate 
the client computer's receiving capacity. 

25 If the server determines that a transmission would not cause a saturation 

condition, it retrieves audio data from the buffer (step 1705) and sends it to the 
destination client computer(s) (step 1 707). If the server determines that a transmission 
would cause a saturation condition, the server then checks whether there is incoming 
audio data from a client computer (step 1715). If there is incoming audio data, the 

30 server places the received audio data in the buffer (step 1717). 

If there is no audio data in the buffer in step 1701 . the server then determines 
whether there is incoming audio data from a client computer (step 1 709). If there is 
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incoming audio data, the server determines whether a transmission of audio data to a 
client computer would exceed the receiving capacity of that client computer or 
otherwise cause a saturation condition at the destination client computer(s) (step 
1711). If the transmission is likely to cause a saturation condition, the server places 
5 the incoming audio data in the buffer of the server (step 1713). If it is safe to transmit, 
the server sends the audio data to the destination client computer(s) (step 1 707). 

FIG. 1 8 illustrates processing steps of a client computer for receiving audio 
data. The steps shown in FIG. 18 may be used by the packet control module 508 of 
FIG. 5B. In FIG. 18 ? the client computer (for example. 202) determines whether there 

10 is audio data in its overflow buffer (for example 412) (step 1801). If there is. the client 
computer 202 determines whether a sound buffer (for example 410) is available (step 
1803). If there is an available sound buffer, the client computer retrieves the first 
audio data from its overflow buffer and feeds it to the available sound buffer (step 
1805). If there is no audio data in its overflow buffer or there is no available sound 

1 5 buffer, the client computer proceeds to check whether there is any newly received 
audio data packet (step 1 807). 

If there is audio data packet newly received from other client computers, the 
client computer 202 determines whether a sound buffer is available (step 1809). If 
there is no available sound buffer, the client computer stores the newly received audio 

20 data in its overflow buffer (step 1811). If there is an available sound buffer, the client 
computer 202 feeds the newly received audio data to the available sound buffer (step 
1813). The client computer's sound mixer (for example 408 of FIG. 4) then mixes the 
signals from the sound buffers (step 1815), and sends the mixed signals to an output 
device such as a speaker to convert the acoustic signal to audible sound (step 1817). 

25 In a preferred embodiment of the invention, each sound buffer is allocated for 

a particular client computer so that audio data received from the same client computer 
is routed to the same buffer for the duration of speech according to the processing 
steps of FIG. 1 8. The end of the speech is indicated by the start/middle/end-of-data 
indicator contained in the payload 504 in one embodiment of the invention. 

30 For example, the sound buffer 410-1 in FIG. 5(B) of the client computer 202 

may be allocated to audio data received from the client computer 204. the sound buffer 
410-2 to the client computer 210, and the sound buffer 410-3 to the client computer 
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212. Thus, when an audio data packet is received from the client computer 204 in step 
1807. the client computer 202 checks the corresponding sound buffer 410-1 to 
determine whether a sound buffer is available for the client computer 204 in step 1809. 
If the sound buffer is available, audio data received from the client computer 204 is 
5 routed to the corresponding sound buffer 410-1 (step 1813). Otherwise, the audio data 
is routed to the overflow buffer 4 1 2 (step 1811). In this embodiment, each sound 
buffer receives audio data originated from a corresponding client computer in a proper 
sequence without interruption by audio data from other client computers for the 
duration of the speech. 

1 0 Unique attributes of the invention will be recognizable to those skilled in the 

art at this point. Unlike prior art conferencing systems, the present invention, in 
accordance with the embodiments shown in FIGS. 1 7-1 8 ? provides an environment 
where users may engage in a conference where a plurality of users are allowed to 
speak simultaneously without losing information or audio data from other users. This 

1 5 functionality is achieved by combining a buffer control mechanism and a multi-party 
conference facility so that all audio data is eventually delivered to the destination 
computers, although some audio data may be delayed. 

FIG. 19 illustrates an alternate embodiment of processing steps for receiving 
audio data for a client computer. The steps shown in FIG. 19 may be used by the 

20 packet control module 508 of FIG. 5B. In FIG. 19. the steps in FIG. 19 generally 
correspond to the steps shown in FIG. 1 8 with one notable exception. Unlike the 
embodiments shown in FIGS. 17 and 18. the embodiment shown in FIG. 19 eliminates 
the need for a client computer to rely on an audio server to control audio data 
transmission. 

25 In the embodiment shown in FIG. 1 9, the client computer determines whether 

an overflow buffer is available on the client computer (step 1917). If there is an 
available overflow buffer, the audio data is placed in the overflow buffer according to 
a suitable queuing method such as FIFO (step 1919). The client computer then checks 
the status of its overflow buffer and determines whether it reached its capacity (step 

30 1 923). In one embodiment of the invention, the client computer (for example. 202) 
compares the volume of received audio data with the available space of its buffers 410 
and 412. When the volume of audio data equals a first predetermined percentage of 
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the available buffer space, the client computer considers the buffers as having reached 
their capacity. The client computer, if the buffer has reached its capacity or there is no 
available space in overflow buffer, transmits an "off" signal to all computers 
participating in the conference call, instructing the computers to stop transmission 
5 until further notice, and changes its reception state to "off 1 (step 1921). 

When space becomes available in the overflow buffer (step 1 905). the client 
computer sends an "on" signal to the computers in the conference call and changes the 
reception state to "on" (step 1909). The computers in the conference call, in response 
to the "on" signal, reinitiate transmission of audio data (including the stored data) to 

1 0 the client computer 202. 

Unique attributes of the embodiment shown FIG. 19 will be recognizable to 
those skilled in the art. Unlike prior art conferencing systems, the present invention, in 
accordance with the embodiment shown in FIG. 1 9. provides an environment where 
users may engage in a conference where a plurality of users are allowed to speak 

15 simultaneously without losing information or audio data from other users without 
requiring a server's assistance in buffer management. This highly desirable 
functionality is achieved by implementing a buffer control mechanism on the client 
computers and combining it with a multi-party conferencing system. 

Figure 20 illustrates an alternate embodiment for processing steps for 

20 controlling audio data transmission for a client computer. The steps shown in FIG. 20 
may be used by the packet control module 508 of FIG. 5B. As with the embodiment 
shown in FIG. 19, the embodiment shown in FIG. 20 provides an audio data 
transmission control method that enables the client computer to control audio data 
transmission and avoid overflow conditions without relying on an audio server. 

25 In FIG. 20, the client computer (for example 202) monitors the volume of 

incoming audio data and compares this volume with the available bandwidth. If the 
volume of incoming audio data reaches a first predetermined percentage ("upper 
level") of the maximum bandwidth of the client computer (step 2001). the client 
computer determines that its bandwidth or reception capacity has been saturated. If 

30 the state of data reception for the client computer is "on" (step 2003). the client 
computer transmits an "off" signal to all computers participating in the conference 
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call, instructing the computers to stop transmission until further notice, and changes 
the state of data reception to "off 1 (step 2005). 

If the volume of incoming audio data is below the upper level, the client 
computer determines whether the volume of incoming audio data is at or below a 
5 second predetermined percentage ("lower level") of the maximum bandwidth (step 
2007). If the volume of incoming audio data is at or below the lower level, the client 
computer determines the state of data reception (step 2009). If the state of data 
reception is "off." the client computer transmits an "on " signal to all computers 
participating in the conference call, instructing the computers to resume transmission. 

10 and changes the state of data reception to "on" (step 201 1). 

As an illustration of the upper level, if the client computer 202 is connected to 
the network 206 through a modem having a 3.200 bytes/sec reception capacity, the 
upper level may be predetermined to be 75%. Thus, in this example, when the volume 
of incoming audio data reaches 75% of 3.200 bytes/sec or 2,400 bytes/sec, the client 

15 computer transmits an "off signal. The exact figure of the upper level is not 
important to the invention and may vary depending on the needs of a'particular 
application. For example, if the client computer is connected to the network 206 via a 
faster interface such as a LAN or a T-l interface, the upper level can be in a range 
between 500 Kbytes/sec and 800 Kbytes/sec. Likewise, the lower level may be set at 

20 25% of the maximum bandwidth in one embodiment of the invention. However, the 
exact figure of the lower level is not important, and may var\ depending on a 
particular application. 

Unique attributes of the embodiment shown FIG. 20 will be recognizable to 
those skilled in the art. In addition to the unique attributes achieved by the 

25 embodiment of FIG. 1 9, the embodiment shown in FIG. 20, eliminates the need to rely 
on buffers to control overflow conditions. This highly desirable functionality is 
achieved by monitoring the available bandwidth of a client computer to detect a 
saturation level, and sending an appropriate signals to other computers to avoid 
overflow conditions. 

30 It will be appreciated by one skilled in the art that the processing steps shown 

in FIG. 20 may be implemented separately or combined with the processing steps 
shown in FIG 1 8 in order to provide audio data transmission control and prevent 
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bandwidth saturation conditions. In a preferred embodiment of the invention, the steps 
shown in FIG. 20 are implemented separately from the steps shown in FIG. 18, and are 
executed periodically (for example, every second) by the client computer. 

FIG. 21 illustrates processing steps for conducting multiple calls and 
5 conferences for a client computer (for example 202) in accordance with one 
embodiment of the invention. The first step shown in FIG. 21 is for the client 
computer to determine whether a conversation request to communicate with the client 
computer is being made by another client computer (step 2101). If there is a 
conversation request, the client computer determines whether the user selects 
1 0 "Hold/Pick Up" button 823 and accepts the conversation request (step 21 03). If the 
user does not accept, the client computer determines whether the user selects the 
"Hang Up" button 825 (step 2105). If the user selects the "Hang Up" button 825, the 
client computer disconnects the incoming call (step 2109) 

If the user decides to accept the conversation request, the client computer 
15 checks to see if any previously initiated conversation is still in progress (step 2111). If 
there is one, the client computer places the current ongoing conversation on hold (step 
21 13) and initiates communication with the new incoming caller (step 2115). 

FIG. 22 illustrates processing steps of a server for establishing a peer-to-peer 
messaging session in accordance with one embodiment of the invention. The first 
20 processing step of FIG. 22 is for a server (for example 240) to determine whether peer- 
to-peer messaging is requested by a client computer (step 2201). If there is a peer-to- 
peer messaging request, the server establishes communication with the recipient client 
computer indicated by the requesting client computer (step 2203). 

Next, the server checks to see if any client computer is behind a firewall (step 
25 2205). If neither client computer is behind a firewall, the server sends instructions to 
both client computers to establish direct peer-to-peer communication (step 2207). If, 
however, either or both of the client computers are behind a firewall, direct peer-to- 
peer messaging is not available and the server sends instructions to both client 
computers to establish communication via the server (step 2209). Direct peer-to-peer 
30 audio messaging is available when, for example, both client computers are capable of 
using UDP as their communication protocol. 



23 



WO 00/60809 PCT/US00/08688 

The foregoing descriptions of specific embodiments of the present invention 
are presented for purposes of illustration and description. They are not intended to be 
exhaustive or to limit the invention to the precise forms disclosed, obviously many 
modifications and variations are possible in view of the above teachings. The 
5 embodiments were chosen and described in order to best explain the principles of the 
invention and its practical applications, to thereby enable others skilled in the art to 
best utilize the invention and various embodiments with various modifications as are 
suited to the particular use contemplated. It is intended that the scope of the invention 
be defined by the following claims and their equivalents. 
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1 . A method of inviting candidate users to a conference call comprising one or 
more participants, wherein each participant is associated with a different end-user 

5 computer, the method comprising: 

originating a conference call request from a participant by selecting a candidate 
user from a list of candidate users that is displayed on a display screen of an 
originating end-user computer associated with said participant; 

transmitting said conference call request from said originating end-user 
1 0 computer to a selected end-user computer associated with said selected candidate user; 

notifying said selected candidate user of said conference call request and the 
identity of said participant originating said conference call request when said selected 
end-user computer receives said call request; 

joining said selected end-user computer to said conference call when said 
1 5 candidate user accepts said conference call request, wherein said candidate user 
becomes a first additional participant in said conference call; 

indicating on a display screen of each end-user computer associated with a 
participant in said conference call that said first additional participant has joined said 
conference call; and 

20 changing a status symbol associated with said first additional participant on 

said display screen of said selected end-user computer to indicate that said first 
additional participant is now in said conference call. 

2. The method of claim 1 wherein said originating step includes the step of 
25 displaying a list of candidate users from a personal contact list stored on said 

originating end-user computer. 

3. A method of communicating between a first end-user computer associated with 
a first user, and one or more second computers, each of which is associated with a 

30 user, wherein said first and said one or more second end-user computers each has a 
display screen and is in communication with a server, said method comprising the 
steps of: 

25 
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forwarding a first signal from said first end-user computer to said server when 
said first user speaks, said first signal including a digital representation of a speech; 

distributing said first signal from said server to each of said one or more second 
end-user computers; 

5 receiving, at said server, one or more responsive signals from said one or more 

second end-user computers, each of said one or more responsive signals generated by a 
different second end-user computer when a user associated with said different second 
end-user computer speaks, each of said one or more responsive signals including a 
digital representation of said speech; 
10 directing an initial responsive signal of said one or more responsive signals 

from said server to said first end-user computer: 

storing subsequent responsive signals of said one or more responsive signals in 
a buffer; and 

sequentially converting said subsequent responsive signals from said buffer to 
1 5 sound at said first end-user computer. 

4. The method of claim 3 wherein said storing step is performed by said first end- 
user computer. 

20 5. The method of claim 3 wherein said storing step is performed by said server. 

6. The method of claim 4 further comprising the steps of: 

sending an off signal to said one or more second end-user computers when a 
bandwidth of said first end-user computer reaches a first predetermined level, thereby 
25 causing said one or more second end-user computers to stop transmission to said first 
end-user computer: and 

sending an on signal to said one or more second end-user computers when said 
bandwidth of said first end-user computer reaches a second predetermined level, 
thereby causing said one or more second end-user computers to resume transmission to 
30 said first end- user computer. 
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7. The method of claim 3 further comprising the step of providing the first user 
with the option to set a pause option: wherein, when said pause option is set. 

each of said one or more responsive signals is allocated to a corresponding 
buffer selected from a plurality of buffers associated with said first end-user computer 
5 while said First user is speaking: and 

a subset of said one or more responsive signals and said plurality of buffers is 
converted to sound when said first user is not speaking. 

8. The method of claim 7 wherein said subset is limited to a maximum of four 
10 signals at any given time. 

9. The method of claim 3 further comprising the step of 

adding a digital representation of an identity of said first user to said first 

signal. 

15 

10. The method of claim 3 further comprising the steps of: 

displaying a broadcast window on said display screen of said first end-user 
computer; 

creating a broadcast window message when a message is typed into said 
20 broadcast window of said first end-user computer; 

sending said broadcast message from said first end-user computer to said 

server: 

distributing said broadcast message from said server to said one or more 
second end-user computers; and 
25 updating said broadcast window on each of said one or more second end-user 

computers with said broadcast message. 

1 1 . The method of claim 3 wherein said one or more responsive signals are 
rejected by said first end-user computer if said one or more responsive signals are from 

30 a user that is on a block list of said first user. 
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12. The method of claim 3 further comprising the steps of: 

opening a message window on said display screen of said first end-user 
computer when said first user selects an indicator that represents a displayed identity 
of a second user that is associated with one of said one or more second end-user 
5 computers; 

transmitting said message from said first end-user computer to said second 
end-user computer associated with said second user: and 

displaying a message window on said display screen of said second end-user 
computer, said message window including a text of said message from said first user. 

10 

13. The method of claim 12 further including the step of providing said second 
user with an option to set a do-not-disturb toggle, and when said do-not-disturb toggle 
is set on. said message window is not displayed on said display screen of said second 
end-user computer. 

15 

14. The method of claim 12 wherein said message window is not displayed on said 
display screen of said second end-user computer when said first user is on a block list 
of said second user. 



20 15. A method of responding to a conversation request sent to a first user from a 
second user associated with a second computer; wherein said first user is associated 
with a first computer having a display screen, said method comprising: 

displaying a conversation request message on said display screen of said first 
computer that identifies said second user while said first user is engaged in one or 
25 more conversations with other users; 

providing said first user with an option to accept said conversation request; 
wherein, when said first user accepts said conversation request message, said first user 
is connected with said second user; and 

updating said display screen of said first computer: wherein said display screen 
30 identifies each conversation in which said first user is participating and the update 
indicates that said first user is speaking with said second user and that conversations 
with other users have been placed on hold. 
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16. The method of claim 1 5 further comprising the concurrent step of providing 
said first user with an option to set a do not disturb toggle, and when said do not 
disturb toggle is set on. said conversation request message is rejected and is not 
displayed on said display screen of said first computer 

1 7. The method of claim 15 wherein said conversation request message is not 
displayed on said display screen of said first computer when said second user is on a 
block list of said first user. 
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AMENDED CLAIMS 

[received by the International Bureau on 25 September 2000 (25.09.00); 
original claims 1, 7, 15 and 16 amended; 
remaining claims unchanged (4 pages)] 



1 . A method of inviting candidate users to a conference call comprising one or more 
participants, wherein each participant is associated with a different end-user computer, the 
5 method comprising: 

originating a conference call request from a participant by selecting a candidate user 
from a list of candidate users that is displayed on a display screen of an originating end-user 
computer associated with said participant; 

transmitting said conference call request from said originating end-user computer to a 
1 0 selected end-user computer associated with said selected candidate user; 

notifying said selected candidate user of said conference call request and an identity of 
said participant originating said conference call request when said selected end-user computer 
receives said call request; 

joining said selected candidate user to said conference call when said selected 
1 5 candidate user accepts said conference call request, wherein said selected candidate user 
becomes an additional participant in said conference call; 

indicating on a display screen of each end-user computer associated with a participant 
in said conference call that said additional participant has joined said conference call; and 
changing a status symbol associated with said additional participant on said display 
20 screen of said selected end-user computer to indicate that said additional participant is now in 
said conference call. 

2. The method of claim 1 wherein said originating step includes the step of displaying a 
list of candidate users from a personal contact list stored on said originating end-user 

25 computer. 

3. A method of communicating between a first end-user computer associated with a first 
user, and one or more second computers, each of which is associated with a user, wherein 
said first and said one or more second end-user computers each has a display screen and is in 

30 communication with a server, said method comprising the steps of: 
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7. The method of claim 3 further comprising the step of providing said first user with the 
option to set a pause option; wherein, when said pause option is set, 

each of said one or more responsive signals is allocated to a corresponding buffer 
selected from a plurality of buffers associated with said first end-user computer while said 
5 first user is speaking; and 

a subset of said one or more responsive signals allocated to said plurality of buffers is 
convened to sound when said first user is not speaking. 

8. The method of claim 7 wherein said subset is limited to a maximum of four signals at 
1 0 any given time, 

9. The method of claim 3 further comprising the step of 

adding a digital representation of an identity of said first user to said first signal. 

15 10. The method of claim 3 further comprising the steps of: 

displaying a broadcast window on said display screen of said first end-user computer; 
creating a broadcast window message when a message is typed into said broadcast 
window of said first end-user computer; 

sending said broadcast message from said first end-user computer to said server; 
20 distributing said broadcast message from said server to said one or more second 

end-user computers; and 

updating said broadcast window on each of said one or more second end-user 
computers with said broadcast message. 

25 11. The method of claim 3 wherein said one or more responsive signals are rejected by 

said first end-user computer if said one or more responsive signals are from a user that is on a 
block list of said first user. 
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12. The method of claim 3 further comprising the steps of: 

opening a message window on said display screen of said first end-user computer 
when said first user selects an indicator that represents a displayed identity of a second user 
that is associated with one of said one or more second end-user computers; 
5 transmitting said message from said first end-user computer to said second end-user 

computer associated with said second user; and 

displaying a message window on said display screen of said second end-user 
computer, said message window including a text of said message from said first user. 

10 13. The method of claim 1 2 further including the step of providing said second user with 
an option to set a do-not-disturb toggle, and when said do-not-disturb toggle is set on, said 
message window is not displayed on said display screen of said second end-user computer. 

1 4 The method of claim 1 2 wherein said message window is not displayed on said 
1 5 display screen of said second end-user computer when said first user is on a block list of said 
second user. 

15. A method of responding to a conversation request sent to a first user from a second 
user associated with a second computer; wherein said first user is associated with a first 
20 computer, said first and second computers having a display screen, said method comprising: 
displaying a conversation request message on said display screen of said first 
computer that identifies said second user while said first user is engaged in one or more 
conversations with other users; 

providing said first user with an option to accept said conversation request; wherein, 
25 when said first user accepts said conversation request message, said first user is connected 
with said second user; and 

updating said display screen of said first computer; wherein said display screen 
identifies each conversation in which said first user is participating and the update indicates 
that said first user is speaking with said second user and that conversations with other users 
30 have been placed on hold. 
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16. The method of claim 15 further comprising the concurrent step of providing said first 
user with an option to set a do-not-disturb toggle, and when said do-not-disturb toggle is set 
on, said conversation request message is rejected and is not displayed on said display screen 
of said first computer, 

17, The method of claim 15 wherein said conversation request message is not displayed 
on said display screen of said first computer when said second user is on a block list of said 
first user. 
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